home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 1 / ETO Development Tools 1.iso / Essentials / MacApp Documentation / MacApp AppleLink Messages / MacApp.Tech$ Jun 89 / V0012-Re Document Cmds & -Jun89 < prev    next >
Encoding:
Text File  |  1989-06-26  |  2.6 KB  |  49 lines  |  [TEXT/GEOL]
  1. Item    0696352                         5-June-89        19:51
  2.  
  3. From:   D0420                           Satori SW, Hugh Rogovy, PRT
  4.  
  5. To:     MACAPP.TECH$                    MACAPP Tech
  6.  
  7. Sub:    RE: Document Cmds & Windows
  8.  
  9. Curtis,
  10.  
  11. I agree with you regarding the "incorrect" assumption that a document should be
  12. closed if all of its windows are closed (hidden).  In fact, we have found it
  13. beneficial (necessary) to create a subclass for TWindow ("TOurWindow") that we
  14. use here as a default for windows that we create.  One of the methods we did
  15. override was TWindow.CloseByUser for exactly the reason you've specified.
  16.  
  17. I also agree with you (although not with as much fervor!) regarding documents
  18. receiving MenuCommand messages without a window being open.  I would really
  19. like to see documents retain control over hiding/showing their own windows, for
  20. instance, irregardless of the fact that the document has no windows visible or
  21. frontmost.  As it stands now, our application class seems to end up handling
  22. quite a few commands that would be better handled by the documents they are
  23. acting upon.  It seems that just before (or maybe even after) TApplication gets
  24. its chance at the command it could pass the message through to any documents
  25. that haven't yet received it (all documents except gDocument).
  26.   Actually, it seems that you could implement this pretty easily yourself by
  27. overriding your TYourApplication.DoSetUpMenus method and calling
  28. TApplication.ForAllDocumentsDo to perform menu setups.  Menu commands could be
  29. taken care of by calling gDocList.FirstThat checking for
  30. somedoc.DoMenuCommand<>gNoChanges.  The only thing that may get you in trouble
  31. here is the ordering of the documents in gDocList.  But if you're careful
  32.  
  33. As far as taking your comments off-line, I would personally prefer that the
  34. discussion remained on MacApp.Tech$.  I love MacApp, but I also want to see it
  35. become the best product possible (geez, I sound like an Apple employee), and I
  36. think everyone can point to something about it that "gets in their way".
  37. Fortunately, the negatives are truly minimal.  I think it's very important that
  38. we as developers utilize this forum to see that MacApp does reach its full
  39. potential, especially if it is going to become THE development platform for the
  40. Macintosh.  As long as we can keep the pointless tirades (I hope this isn't
  41. considered one) to a bare minimum I think MacApp.Tech$ could become very
  42. valuable in pointing MacApp development in a direction that will satisfy the
  43. needs (and wants) of the vast majority of Apple developers.
  44.  
  45.  
  46.                                         Chris Le Croy
  47.                                         Satori Software
  48.  
  49.